N4 lets you store additional information for which no pre-defined field exists in the database by using flex fields. For example, you can override a flex field for the Unit entity to store some unit delivery requirement information for which there is no pre-defined field in N4.
N4 supports different kinds of flex fields:
System flex fields: Reserved database fields that you can customize according to your requirements.
Dynamic flex fields: Dynamically defined fields added to a system entity. These flex fields are different from system flex fields in that they support additional attributes and relations. You can add them to entities that do not support system flex fields, such as Shipper or Agent, or to entities that support system flex fields but for which all system flex fields have been used up, or to create a foreign-key relation to another entity or data type not supported by system flex fields.
Dynamic entity fields: Essentially the same as dynamic flex fields but related to a dynamic custom entity, not a system entity.
The following matrix can help you decide when it is best to use system flex fields versus dynamic flex fields.
|
|
System Flex Fields |
Dynamic Flex Fields |
|---|---|---|
|
Ease-of-use |
X |
|
|
Support of data types boolean and system-delivered enumeration |
|
X |
|
Ability to build custom functionality requiring new tables |
|
X |
|
Support of many-to-one relations |
|
X |
|
Free licensing |
X |
|
The Group ID that you assign to a flex field determines the location of the flex field in the various inspectors, forms, and list views. For more information, see Location of flex fields (on page 1).
For a list of available flex fields and their various attributes, see Available flex fields (on page 1). For a visual illustration of what is involved in configuring flex fields, see the process flow (on page 1) diagram.
Notes
Only standard variforms support flex fields. Hardcoded ULC screens, such as Pre-advise Export, may not support flex fields.
N4 does not record updates that affect only flex fields on the History, Events tab. If an update also includes other fields, N4 captures the full update, including all field changes, in a history event that appears on the History, Events tab. Even if N4 does not record the event against the entity on the History, Events tab, N4 Mobile sends all field changes to N4 when you save.
You can also display flex fields in XPS. For more information, see Configure N4 flex fields for XPS (on page 1).
To use a flex field:
Override a flex field at the required scope level.
For more information, see Configuring a flex field (on page 1).
Use the appropriate data entry forms to edit the value stored in a flex field. For more information, see Location of flex fields (on page 1).
Add the flex field to one or more of the following:
A report design to display flex field data in a report.
For more information on the tag names for the various flex fields, see the corresponding reporting entity.
A gate form to enable gate clerks to enter unit data for a flex field at the gate.
For more information, see Tran Type form.
If you configure unit flex fields in a gate form, make sure to include the ApplyFlexFieldsToUnit and ApplyInspectionUnitFlexFields business tasks in your gate configuration as needed.
A printer XSL layout file to print flex field data entered at the gate on a gate ticket.
For more information, see XML data elements.
A mapping file to receive and send data for a flex field in an EDI message.
For more information, see EDI Message Map form.
An XML data import file to import unit flex field data in N4 using the SNX Importer form.
For more information on the element names for the various flex fields, see the snx.xsd schema file.
Optionally, to display a flex field value in XPS you can add the associated attribute to the settings.xml and SPARCS settings.txt files under the #ATTRIBUTE section. For more information, see Viewing flex fields in XPS (on page 1).
In This Section